Subject: last call for comments

From: "[email-masked]" <[email-masked]>
Date: Sat, 24 Sep 94 16:44:34 EDT

Wayne,
Sorry I missed your deadline of yesterday for last comments - I couldn't
squeeze in one last review of the mailing list etc. in those 3 days.

Just some minor stuff:
Frank's response to Paul Brittain's 2 Sep append did not address Paul's
suggested wording about NB names, so you may want to consider them:
>    All blanks or nulls at the end of NetBIOS names in this control vector
>    are ignored, as are trailing blanks and nulls in any NetBIOS names to
>    which this data is compared. NetBIOS names which have fewer than 16 bytes
>    and which do not end with '*' are not assumed to have a trailing '*';  the
>    "wildcard" character must be explicit.

With regard to Mark Duffy's post, I think we decided on FFs for
the various ctrl header fields (maybe 00s, I don't remember) but it
doesn't look like the capex section captures the decision.  I agree
with Mark it would be good to add a sentence.  Frank's 13 Sep version
already says capex uses a control SSP header.

You might add the words "Allowed @" above the "Runtime" column of the
section 5.5 table to clarify that "Y" here means a CV is allowed but
not required.  In retrospect, "Supported SAP list" looks out of place
in the table; it would have been nice to have id's so the required
4 are in order at the top.  I suppose it's too late for such a change.
Peter

---

From: Wayne Clark <[email-masked]>
Date: Tue, 27 Sep 94 09:56:52 EDT

Peter -

    Some comments appended below.

Wayne

>already says capex uses a control SSP header.

    I think most buffer management routines would zero-fill the memory
    on a get operation.  What I am more inclined to do is to identify the
    fields in the SSP header that are relevant for a CapEx.  There
    aren't that many:  (hope I haven't missed any)

	00 .. Version Number (== 0x01)
	01 .. Header Length (== decimal 72)
	02 .. Message Length (same as LL in GDS Variable)
	14 .. Message Type  (== CAP_EXCHANGE)
	16 .. Protocol Id (== 0x42)
	23 .. Message Type  (== CAP_EXCHANGE)

    and merely leave the rest alone.  That way, if there is a buffer
    management function out there that does not zero-fill, we won't
    impose more overhead just for CapEx.  If there are strong opinions
    that we ought to specify zero-fill for unused fields, then we
    could do that.  I think 0xFF fill is a bad idea.

>4 are in order at the top.  I suppose it's too late for such a change.

    We'll make the table column header change.  As far as reordering the
    CVs at this point, we could probably do it just prior to the final
    submission for closed pages.  I've reordered them about 4 times
    already throughout the life of CapEx ... they just won't stay
    put :-).

    If there are strong opinions one way or the other out there, please
    speak up.  I'm inclined to leave them alone just to reduce the
    number of edits we have to do.

    We'll send out an updated Section 5 later today  to reflect some of the
    recent changes.